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Reply to Office Action dated August 2, 2004 

REMARKS 

I. Summary of the Office Action and This Reply 

Claims 1-14 and 17-20 are pending in the application. The Examiner has 
rejected claims 1-8, 13-14 and 17 under 35 U.S.C. §1 02(e), asserting anticipation by 
U.S. Patent No. 6,453,468 to D'Souza ("D'Souza"). The Examiner has rejected 
claims 9-12 and 18-20 under 35 U.S.C. §1 03(a), asserting obviousness over 
D'Souza in view of Applicant's Admitted Prior Art ("AAPA"). 

Claims 1, 2, 3, 7, 9, 11, 13, 14, and 17-20 are amended herein. Previously 
withdrawn claims 15 and 16 are canceled herein. New claims 21 and 22 are added. 
No new matter is added. 

II. Discussion of Cited Art 

U.S. Patent No. 6,453.468 to D'Souza 

D'Souza states that software upgrades were previously performed on a 
system-wide basis by waiting until a time of low usage, taking the whole computer 
system offline momentarily (e.g. servers A, B and C), loading new upgraded 
software onto multiple servers of the computer system (e.g. servers A, B and C), 
and then bringing the entire computer system back online (including servers A, B 
and C) to allow incoming transaction requests to be handled by the new upgraded 
software. Col. 3, lines 39 - 49. 

D'Souza discloses a method for improving reliability while upgrading software 
in a computer system including a cluster of redundant servers. The method involves 
upgrading only a few servers of a server cluster at a time. Accordingly, reliability and 
service quality risks associated with software upgrade operations are reduced by 
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allowing upgraded software to be gradually phased in on only a percentage of the 
servers that eventually need to be upgraded. Col. 7, lines 1-6; col. 14, lines 1-30 
and 58-61 . Therefore, if a particular server with upgraded software fails, the 
remaining servers' of the server cluster, which continue to run the old software, 
remain available to service transaction requests. D'Souza contemplates that the 
remaining servers' software is upgraded after the initial subset of servers have 
proven themselves to be reliable and stable. 

Accordingly, by way example, if servers A, B, and C are in a server cluster for 
servicing transaction requests, D'Souza teaches a method involving initially 
upgrading software only on server A, before upgrading software on servers B and C. 

III. Response to 102 Rejections 

The Examiner has rejected claims 1-8, 13-14 and 17 under 35 U.S.C. 
§1 02(e), asserting anticipation by D'Souza. 

A rejection under 35 U.S.C. § 102 is proper only if each and every element of 
the claim is found in a single prior art reference. MPEP § 2131. 

Claims 1-8, 13. 14. 21 and 22 

As discussed above, D'Souza discloses that fewer than all servers in a server 
cluster are taken offline and upgraded with new software at a time. However, in 
accordance with D'Souza, the entire server having software to be upgraded is taken 
offline when any one of its programs is upgraded . Therefore, in accordance with 
D'Souza, a particular server (server A) and all of its resources are unavailable during 
the upgrade of a software module on server A . Accordingly, if server A stores three 
distinctly different software modules for servicing transaction requests (such as 
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modules 1, 2, and 3), server A is not capable of servicing transaction requests 
involving modules 2 and 3 while module 1 is being upgraded. This is similar to the 
discussion in the Background of the Invention section of the present application (see 
page 5, lines 15-19) and is contrary to the claimed invention. 

In contrast to D'Souza, claim 1 is directed to a method for upgrading a 
server's software that involves (1 ) preventing the server from servicing client's 
requests for a first computer program, while simultaneously (2) permitting the same 
server to service client requests for other computer programs retrievable from the 
server. Accordingly, the entire server is not taken offline when a single application 
supported by the server needs to be upgraded . Instead, the server continues to 
service client requests for other computer programs while a particular computer 
program is being upgraded. Therefore, in the example above, a particular server 
computer (server A) remains capable of servicing transaction requests involving 
software modules 2 and 3 while server A is having module 1 software upgraded. 
This is neither taught nor suggested by D'Souza. 

Claim 1 is amended herein for clarity to emphasize that the "server" 
referenced relates to particular server computer hardware, and not a logical server 
cluster. Accordingly, "application server" has been amended to "server computer" for 
clarity, in view of the definition of a "server" as a "server computer" at page 1 , line 10 
of the application. 

For at least these reasons, claim 1 is patentable. Claims 2-8, 13 and 14 
depend from claim 1 and are likewise patentable. Therefore, reconsideration and 
withdrawal of the rejections of claims 1-8, 13 and 14 are requested respectfully. 
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Additionally, claim 3 further recites that preventing the application server from 
receiving new requests involves sending a signal to a router to instruct the router to 
stop routing requests for the to-be-u paraded computer program to the server. The 
Examiner asserts that this is disclosed in D'Souza at col. 3, lines 28-38 and col. 14, 
lines 9-41 . Contrary to the Examiner's assertion, there is no such disclosure in 
D'Souza. Claim 3 recites that the instruction to the router is made on a per-program 
basis. In other words, the instruction is to stop routing requests only for a particular 
program . 

In contrast, any such disclosure in D'Souza relates to a stop in sending of all 
requests to a particular offline server which may include more than just the software 
that is to be upgraded; such routing decisions are not made on a per-program basis . 

Claims 4, 5 and 6 elaborate further, and relate to identification of a single 
computer program, e.g. using an identification code such as a URL or filename, 
which are program specific, not server specific. These features are neither taught 
nor suggested by D'Souza. 

The Examiner is reminded of the requirement of 37 CFR §1.1 04(c)(2) to 
identify the particular part of a reference that is relied upon , and is invited to identify 
with specificity any relevant portion of D'Souza if it is believed that D'Souza 
discloses use of such instructions on a program-specific basis. 

For at least these additional reasons, claims 3, 4, 5 and 6 are patentable, and 
reconsideration and withdrawal of the outstanding rejections are requested 
respectfully. 

New claim 21 is similar to claim 3 and further expressly recites what is implicit 
in claim 3, namely that sending a signal to a router to instruct the router to stop 
routing requests for the computer program to the server computer further involves 
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concurrently permitting the router to continue routing requests for other computer 
programs to the server computer . Claim 21 is therefore patentable for reasons 
similar to those discussed above for claim 3. New claim 22 is similar to claim 21 but 
depends directly from claim 1, and is likewise patentable. 

Claim 17 

Independent claim 17 is directed to a method involving instructing a router to 
stop routing requests for a computer program to a server computer while permitting 
said router to continue routing requests for other computer programs to the server 
computer. Accordingly, claim 17 is patentable for reasons similar to those set forth 
above for claims 3, 21 and 22. 

Further, there is no teaching or suggestion in D'Souza of monitoring the 
server's active sessions on a per-program basis, and waiting until the server is no 
longer supporting a current client request for the computer program. This is not 
necessary when simply removing a single server from a server cluster, as in 
D'Souza. 

For at least these reasons, reconsideration and withdrawal of the rejection of 
claim 17 are requested respectfully. 

IV. Response to 103 Rejections 

The Examiner has rejected claims 9-12 and 18-20 under 35 U.S.C. § 103(a), 
asserting obviousness based on D'Souza in view of what is asserted to be AAPA. 

A section 103 rejection is proper only if all claim limitations are taught or 
suggested by the cited art. MPEP §2143. 
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As discussed above, there are various limitations of the claims from which 
claims 9-12 and 18-20 depend that are neither taught nor suggested by D'Souza, 
and further those limitations are neither taught nor suggested by AAPA. Further, 
claims 9-12 and 18-20 depend from allowable claims, as discussed above, and are 
therefore likewise patentable. It is specifically noted that arguments in traversal of 
the characterization of AAPA are held in abeyance as it is believed that allowance 
may be properly granted in view of the discussion above. 

CONCLUSION 

In view of the foregoing amendments and remarks, Applicants believe claims 
1-14 and 17-22 to be patentable and the application in condition for allowance. 
Applicants respectfully request issuance of a Notice of Allowance. If any issues 
remain, the undersigned requests a telephone interview prior to the issuance of an 
action. 



Dated : September 21, 2004 



Respectfully submitted, 



Gregory) Si Bernabeo 
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